Multi-Platform Compiling

ABSTRACT

Cross-compiling, by a multi-version compiler, may produce complied code targeted to a specified release version of a programming platform supported by the compiler. The specified version may be different from a default version of the programming platform targeted by the compiler. Thus, the multi-version compiler may cross-compile source code to generate compiled code for different versions of the programming platform. A developer may specify the target version using a single compiler option and the compiler may, in response, cross-compile for the target version without requiring any additional options to be configured by the user. The multi-version compiler may include library data regarding multiple versions of the programming platform, preventing a developer from having to locate and provide the necessary library data for each targeted version.

This application is a continuation of U.S. patent application Ser. No.14/957,530, filed Dec. 2, 2015, claims priority to U.S. ProvisionalPatent Application Ser. No. 62/261,257, filed Nov. 30, 2015, entitled“Multi-Platform Compiling”, which are hereby incorporated by referenceherein in their entirety.

BACKGROUND

Traditionally, cross-compiling, that is compiling a software moduleusing one version of a programming platform for execution according to adifferent version of the programming platform, requires the developer tocorrectly set multiple compiler and/or linker options. By default,however, many compilers compile against the most-recent version of theprogramming platform, such as by using the application programminginterfaces (APIs) targeting the current version of the programmingplatform. Thus, a compiled program may accidentally use APIs onlyavailable in the current version of the programming platform. Suchprograms may or may not run correctly (or cannot execute at all) onolder (or, in general, different) versions of the programming platform,regardless of the particular values used when configuring the compiler.

Using a Java-based example, the javac compiler can be used tocross-compile libraries (or other software modules) for older versionsof the Java Runtime Environment (JRE), Java Development Kit (JDK) or asimilar bundling of the Java platform. For instance, the javac compilerprovides two command line options (i.e., -source and -target) which canbe used to select the version of the Java Programming Language used bythe compiler during compilation as well as the target version of theexecutable output format (e.g., as realized by class files) used for theclass files produced.

Properly cross-compiling traditionally frequently requires correctlysetting multiple compiler and/or linker options. For instance,cross-compilation of libraries for older versions of a JRE and/or JDKtraditionally requires the developer to configure up to three options(e.g., -source, -target, and -bootclasspath). However, configuring theseoptions is generally error prone since developers frequently fail to set(or set incorrectly) one or more of the options. The developer may alsohave to locate and/or provide the compiler with appropriate library data(e.g., rt.jar) for the target version of the programming platform.

Requiring multiple options to be correctly set often results in spuriouserror/bug reports that may actually result from incorrect options beingused or from a failure to set a particular option. While some compilersmay issue warnings related to incorrectly set options (or for optionsthat were not set), setting multiple compiler/linker options forcross-compiling (e.g., for different versions) may be inconvenient anderror-prone.

SUMMARY

Described herein, according to various embodiments, are techniques forperforming cross-compiling by a multi-version compiler. For example, amulti-version compiler may cross-compile source code to generatecompiled code (e.g., software modules, class files, libraries, etc.) fordifferent versions (e.g., families, editions, releases, updates, etc.)of a programming platform. For instance, in one embodiment, a user(e.g., a programmer or developer) may specify the target release versionof the programming platform using a version option within a compilecommand. In response, the multi-version compiler may cross-compile thesource code (e.g., using the appropriate programming language version,executable output format and base library according to the specifiedrelease version) without requiring any additional options specified bythe user.

A multi-version compiler may receive a compile command that includes aversion option specifying a particular release version of a plurality ofprogramming platform versions supported by the compiler. The targetrelease version of the programming platform may in some embodimentsrepresent a combination of a source language version, a target classfile version (e.g., executable output version) and core library version.In response to the compile command, the compiler may access library datafor a specified version of the programming platform from a library datarepository of the compiler. The library data may include, but may not belimited to, information regarding the types, APIs, interfaces, etc.,used when compiling source code according to the specified releaseversion. The library data repository may include library data forvarious versions (e.g., families, editions, releases, updates, etc.) ofa programming platform supported by the compiler.

The compiler may then compile the source to generate compiled codetargeted to a specified version of the programing platform according toa particular version of the programming language used to write thesource code (which may be different that the default or current versionof the programming language used by the compiler) and using the librarydata against which the source files are to be compiled.

In some embodiments, a single compiler option may be used to specify therelease version. For example, in one Java-based embodiment, a singleoption, such as “-platform” or “-release”, may be used to specify therelease version for the compiler to use when compiling source code.

Additionally, the multi-version compiler (or a development systemincluding the multi-version compiler) may include (or provide) thelibrary data, rather than requiring the user (e.g., programmer ordeveloper) to obtain, install and specify the location of, library datafor the targeted version of a programming platform when cross-compiling.Library data may include information regarding different versions of aprogramming platform for use by a compiler in order to producecross-compiled code targeting those different versions. For example,according to one Java-based embodiment, a current version of the JavaRuntime Environment (JRE), Java Development Kit (JDK) or a similarbundling of the Java platform, may be configured to include and/orprovide library data (e.g., type, API and/or interface information, suchas in an rt.jar or ct.sym file) for various other versions of the JREfor use by the javac compiler when cross-compiling as described herein.Thus, a developer may not have to locate and provide the necessarylibrary data for each targeted version.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a logical block diagram illustrating a multi-version compiler,as described herein according to one embodiment.

FIG. 2 is a flowchart illustrating one embodiment of a method forcross-compiling by a multi-version compiler, as described herein.

FIG. 3 is a flowchart illustrating one embodiment of a methodcross-compiling for multiple versions of a programming platform,according to one embodiment.

FIG. 4 is a flowchart illustrating one embodiment of a method fordetermining library data for a particular version of a programmingplatform using baseline and differential library data, as describedherein.

FIG. 5 is a logical block diagram illustrating a library data repositoryincluding both baseline and differential library data, according to oneembodiment.

FIG. 6 is a logical block diagram illustrating a library data repositoryusing a multi-version directory structure, according to one embodiment.

FIG. 7 is a flowchart illustrating one embodiment of method foraccessing library data using a multi-version directory structure, asdescribed herein.

FIG. 8 is a logical block diagram illustrating a library data repositoryincluding multiple platforms with multiple versions, according to oneembodiment.

FIG. 9 illustrates an example computing device that may be used in someembodiments.

DETAILED DESCRIPTION OF EMBODIMENTS

Described herein are a system and methods for cross-compiling fordifferent versions of a programming platform, according to variousembodiments. When cross-compiling, such as when a multi-version compilerproduces compiled code targeted to a different version (e.g., family,edition, release, update, etc.) of a programming platform that thecompiler targets by default, the developer may specify the targetrelease version using a single compiler option, according to someembodiments. As noted above, the target release version of theprogramming platform may in some embodiments represent a combination ofa source language version, a target class file version (e.g., executableoutput version) and core library version. Thus, a programming platform,as described herein, may in some embodiments be considered a tuple ofconfiguration information used by a compiler during compilation. Theconfiguration information stored in such a tuple may include (orspecify) a triple of source version (e.g., of the programming language),executable output format, and a set of default libraries, according toone embodiment.

A multi-version compiler may be able to compile source code usingvarious versions of the source programming language (e.g., as describedby the programming language specification). A multi-version compiler mayalso be able to generate compiled code according to various executableoutput formats and may be able to utilize different base platformlibraries against which the source files are compiled. For instance, inone Java-based example, the javac compiler may be able to compile sourcecode using various versions of the Java Programming Language (e.g., asdescribed by the Java Language Specification), while supporting variousexecutable output formats (e.g., class file formats described by theJava Virtual Machine Specification) using various platform libraries.Thus, the format and semantics of the executable output may be versionedsimilarly to the format and semantics of the source programminglanguage. Traditionally, the javac compiler utilized different compileoptions (e.g., -source, -target and -bootclasspath) to specify theparticular versions used during compilation. However, a multi-versioncompiler, as described herein, may utilize a single compile option(e.g., “-platform” or “-release”) to specify a target release thatindicates or identifies a particular version of the programminglanguage, a particular executable output format, and a particularversion of the base platform libraries to be used by the multi-versioncompiler.

In some embodiments, one or more constraints may be placed on theversions specified by target programming platform. For example, theversion of the executable output format specified by a particular targetprogramming platform may be required to be higher (e.g., chronologicallylater) than the version of the source programming language alsospecified by that same target programming platform. Similarly, in someembodiments, particular versions of the base platform libraries may notbe appropriate for use with certain versions of source programminglanguage (e.g., certain types within the libraries may have to beavailable to support certain source constructs). Thus, in someembodiments target programming platforms may be constrained to certainpairs of source programming language versions and base platform libraryversions. However, in other embodiments, no constraints may be placed onthe particular versions (e.g., of source programming language,executable output format, and base platform libraries) specified by aparticular target programming platform.

Thus, cross-compiling may involve a multi-version compiler producingcode for a version of a programming platform that is different than adefault version that the compiler targets normally. A multi-version (orcross-platform) compiler may detect the fact that a user (e.g.,programmer or developer) desires to compile source code targeted to aparticular release version out of multiple release versions of aprogramming platform supported by the compiler. For example, thecompiler may receive a compile command that includes a version optionspecifying the target release version of the programming platform and,in response, may compile the source code according to a particularversion of the programming language, generating compiled code accordingto a particular executable output format (e.g., a particular class fileformat) and using library data for a target version to produce compiledcode (e.g., a software module, application, class file, object code,library, etc.) targeted to the specified release version of theprogramming platform.

While, for purposes of illustration, the following description uses theJava™ programming language (or a language closely related to Java™), thetechniques described may be used with any compiler that supportscross-compiling for different versions of a programing platform. Thetechniques may also be used for object-oriented languages or fornon-object-oriented languages (such as various procedural languages),according to various embodiments. Thus, while the techniques describedherein are described mainly in terms of Java-based systems, the samemethods, techniques and mechanisms may also apply to (and may be usedwith any of various systems and/or languages. For instance, the methods,techniques and/or mechanisms described herein may be used with JavaDevelopment Kits (JDKs), Java Runtime Environments (JREs), Java StandardEdition (SE), Java Micro Edition (ME), as well as with virtually anylanguage/system that allows compiling/linking for various versions of aprogramming platform. Furthermore, a version of a programming platform,as described herein may also represent any of various versions,families, releases, editions, updates, etc., of a programming platform,according to various embodiments.

In the following detailed description, numerous specific details are setforth to provide a thorough understanding of claimed subject matter.However, it will be understood by those skilled in the art that claimedsubject matter may be practiced without these specific details. In otherinstances, methods, apparatuses or systems are not described in detailbelow because they are known by one of ordinary skill in the art inorder not to obscure claimed subject matter.

While various embodiments are described herein by way of example forseveral embodiments and illustrative drawings, those skilled in the artwill recognize that embodiments are not limited to the embodiments ordrawings described. It should be understood that the drawings anddetailed description thereto are not intended to limit the embodimentsto the particular form disclosed, but on the contrary, the intention isto cover all modifications, equivalents and alternatives falling withinthe spirit and scope of the disclosure. Any headings used herein are fororganizational purposes only and are not meant to be used to limit thescope of the description. As used throughout this application, the word“may” is used in a permissive sense (i.e., meaning having the potentialto), rather than the mandatory sense (i.e., meaning must). Similarly,the words “include”, “including”, and “includes” mean including, but notlimited to. Additionally, when used in the claims, the term “or” is usedas an inclusive or and not as an exclusive or. For example, the phrase“at least one of x, y, or z” means any one of x, y, and z, as well asany combination thereof.

Some portions of the detailed description which follow are presented interms of algorithms or symbolic representations of operations on binarydigital signals stored within a memory of a specific apparatus orspecial purpose computing device or platform. In the context of thisparticular specification, the term specific apparatus or the likeincludes a general purpose computer once it is programmed to performparticular functions pursuant to instructions from program software.Algorithmic descriptions or symbolic representations are examples oftechniques used by those of ordinary skill in the signal processing orrelated arts to convey the substance of their work to others skilled inthe art. An algorithm is here, and is generally, considered to be aself-consistent sequence of operations or similar signal processingleading to a desired result. In this context, operations or processinginvolve physical manipulation of physical quantities. Typically,although not necessarily, such quantities may take the form ofelectrical or magnetic signals capable of being stored, transferred,combined, compared or otherwise manipulated. It has proven convenient attimes, principally for reasons of common usage, to refer to such signalsas bits, data, values, elements, symbols, characters, terms, numbers,numerals or the like. It should be understood, however, that all ofthese or similar terms are to be associated with appropriate physicalquantities and are merely convenient labels. Unless specifically statedotherwise, as apparent from the following discussion, it is appreciatedthat throughout this specification discussions utilizing terms such as“processing,” “computing,” “calculating,” “determining” or the likerefer to actions or processes of a specific apparatus, such as a specialpurpose computer or a similar special purpose electronic computingdevice. In the context of this specification, therefore, a specialpurpose computer or a similar special purpose electronic computingdevice is capable of manipulating or transforming signals, typicallyrepresented as physical electronic or magnetic quantities withinmemories, registers, or other information storage devices, transmissiondevices, or display devices of the special purpose computer or similarspecial purpose electronic computing device.

FIG. 1 illustrates a workflow for cross-compiling source code using amulti-version, or cross-platform, compiler, according to one embodiment.According to the illustrated embodiment, the workflow begins when amulti-version compiler, such as multi-version compiler 100, receivessource code 150. In various embodiments, source code 150 may bespecified in any of various high-level and/or object-orientedprogramming languages, such as Java™, C#, and/or other languages. Forinstance, in one embodiment, source code 150 may be a set of .javafiles.

The multi-version compiler 100 may compile the source code 150 togenerate compiled code 170, such as to produce an executable version ofthe source code, targeted to a particular release version of aprogramming platform supported by the compiler. As noted above, aparticular release version may indicate a particular version of theprogramming language, a particular executable output format (e.g., classfiles according to a Java-based example) and a particular version oflibrary data (e.g., base platform libraries) to be used duringcompilation, according to some embodiments. For example, multi-versioncompiler 100 may by default compile source code for one release versionof the programming platform (e.g., using a default version of theprogramming language, a default executable output format, and using adefault version of the library data). However, multi-version compiler100 may be configured to cross-compile source code 150 to producecompiled code 170 targeting a different release version of theprogramming platform (e.g., using a different version of the programminglanguage, a different executable output format, and/or using a differentversion of the library data). For example, in one embodimentmulti-version compiler 100 may represent a Java-based compiler that, bydefault, compiles software modules for a current version (e.g., family,edition, release, update, etc.) of the JRE and/or JDK, but which mayalso be configured to cross-compile to produce compiled code for otherversions (e.g., other families, editions, releases, updates, etc.) ofthe JRE and/or JDK. For instance, a Java compiler (e.g., the javaccompiler) from a current version of the JRE and/or JDK may be used tocross-compiler for older versions (e.g., older families, editions,releases, updates, etc.) of the JRE, as one example embodiment.Additionally, the techniques described herein with reference to the JREapply equally to the JDK or a similar bundling of the Java platform.Similarly, the techniques described herein with reference to the JDKapply equally to the JRE or a similar bundling of the Java platform.

In some embodiments, two different target release versions of aprogramming platform may indicate the same version of the programminglanguage but different executable output formats and/or differentlibrary data versions. Alternatively, different target release versionsof a programming platform may indicate different versions of theprogramming language while indicating the same executable output formatand/or library data versions. Thus, according to various embodiments, arelease version may indicate a particular version of the programminglanguage, a particular executable output format and a particular versionof library data to be used during compilation, and different releaseversions may vary by indicating different versions of one or more of theoptions.

Multi-version compiler 100 may receive compile command 160 that includesversion option 165. Compile command 160 may represent any of variousmechanisms for initiating a compile. For example, in one embodiment,compile command 160 may represent a command issued via a command lineinterface and thus may be part of executing the compiler. A command lineinterface may be used to execute the compiler and may also specify thesource code, such as source code 150, and version option 165, accordingto one embodiment. In other embodiments, compile command 160 mayrepresent a command issued via programmatic interface, such as via amake utility, an integrated development environment (IDE), a runtime(e.g., just-in-time) compile utility, or virtually other developmenttool, whether command line based, graphical user interface (GUI) based,or without any user interface. For instance, in one Java basedembodiment, the javac compiler may be invoked via a command lineinterface or via a programmatic interface, either directly by adeveloper or by any of various development tools.

In some embodiments, multi-version compiler 100 may include one or moresub-modules, such as command interface 120, configured to receivecompile commands (such as compile command 160), identify the optionsincluded with the compile command, such as version option 165 withincompile command 160, and pass information to other parts ofmulti-version compiler, such as to compile engine 110. Compile engine110 may be configured to perform the actual compiling of source code,according to some embodiments. While illustrated as separate entitieswithin multi-version compiler 100, in some embodiments, commandinterface 120 and/or compile engine 110 may not be separate modules orentities, but instead may represent various functions or featuresperformed by multi-version compiler 100.

As part of cross-compiling for different versions of a programmingplatform, multi-version compiler 100 may be configured to locate, accessand utilize information regarding the various versions, such as bylocating, accessing and utilizing library data 140A, 140B, 140C, and/or140D in library data repository 130. For instance, command interface120, compile engine 110 and/or some other part of multi-version compiler100 may be configured to access library data from library datarepository 130. Multi-version compiler 100 may be configured to accesslibrary data repository 130 in response to compile command 160.Multi-version compiler 100 may determine which specific library data toaccess based on version option 165, which may specify a particularrelease version of the programming platform which may indicate aparticular set of library data.

The library data repository may include library data for variousversions (e.g., families, editions, releases, updates, etc.) of aprogramming platform libraries supported by the multi-version compiler.Additionally, in some embodiments, the library data for the variousversions of the programming platform may represent various versions ofbase platform libraries corresponding to various programming platforms.

In some embodiments, library data 140A-D may represent any of varioustypes of information required by multi-version compiler 100 in order toproperly generate compiled code targeted to a particular version of aprogramming platform. For instance, in one Java-based embodiment,library data 140 may represent various type and/or interface information(e.g., such as may be found in an rt.jar or ct.sym file) regarding thetarget version of the programming platform.

While traditionally a developer may be required provide library data(e.g., rtjar file) required for cross-compiling, in some embodiments,library data for the various versions supported by multi-versioncompiler 100 may be provided as part of multi-version compiler 100. Forinstance, both multi-version compiler 100 and library data repository130 (including library data 140A-D) may be installed at the same time,by the same installation procedure, or as part of a single installation,according to various embodiments.

While library data repository 130 is illustrated as include four sets oflibrary data, a library data repository may include virtually any numberof set of library data in various embodiments. Additionally,multi-version compiler 100 may support multiple programming platformsand therefore may be configured to generate compiled code targeted tovarious versions of different platforms. For instance, in one exampleembodiment, multi-version compiler 100 may be configured to compile Javasource code into compiled code (e.g., class files) targeted to JavaStandard Edition (Java SE), Java Enterprise Edition (Java EE), JavaMicro Edition (Java ME), and/or other Java-based platforms, such asJavaFX. Additionally, multi-version compiler 100 may be configured togenerate compiled code targeted to individual sub-versions (e.g.,releases, updates, etc.) within versions of a targeted platform.Additionally in some embodiments, a base library used during compilationmay include two fundamental parts and each part may be updatedindividually between library releases.

For instance, in one Java-based example, a base library may include theJava SE libraries (e.g., standardized under the Java Community Process,typically in the java.* and javax.* packages) and the Java DevelopmentKit (JDK) specific APIs (e.g., typically in the jdk.* or com.sun.*packages). Within a given update release family (e.g., JDK 8 and itsupdates) the base library may change from release to release. Forexample, the JDK-specific API portion may be updated, such as support anew feature. Additionally, however, the Java SE portion of the librarydata may also be updated. In some embodiments, one part of a baselibrary (e.g., the Java SE portion of the API) may only be updated forplatform releases, such as updating from JDK 7 to JDK 8 and updatingfrom implementing the Java SE 7 specification to the Java SE 8specification, according to one Java-based example. Thus, amulti-version compiler may be able to target (and use) any particularversion, sub-version, or update of library data when compiling and thetargeted release version of the programming platform may, in general,indicate any particular version, sub-version, or update of library data,according to various embodiments.

While FIG. 1 illustrates library data repository 130 included with, oras part of, multi-version compiler 100, in some embodiment, library datarepository 130, and the library data 140A-D within, may be storedseparately from, but accessible by, multi-version compiler 100, whilestill being considered part of multi-version compiler 100. For example,in one embodiment, library data repository 130 may be stored remotely ona storage device accessible by multi-version compiler 100 (e.g., such asvia a network, intranet, internet, etc.). In another embodiment, librarydata repository 130 may reside (e.g., may be stored) on the same system(whether or not on the same storage device) as multi-version compiler100 without actually being included within multi-version compiler 100.Furthermore, in some embodiments, library data repository 130 may bedistributed among various locations, such that some library data islocal to multi-version compiler 100 while other library data is remotefrom multi-version compiler 100. When stored remotely from multi-versioncompiler 100, library data repository 130 and the library data 140within, may still be considered part of multi-version compiler 100.

While described herein mainly in terms of the Java Programming Languageand Java-based platforms (e.g., Java, Java ME, Java SE, JDKs, JREsetc.), the techniques, methods and/or mechanisms described hereinregarding cross-compiling for multiple platform versions may be alsoapply (and may be used for) other programming languages and/orplatforms. For example, the techniques, methods and/or mechanismsdescribed herein may be used with any of various programming language(s)and/or platform(s), such as Java, C, C++, with other platforms, orvirtually any multi-version or multi-version compiler regardless of theparticular programming language(s) and/or platform(s) it is used with.For instance, a multi-version C# compiler may also be configured toutilize the techniques described herein to implement compiling forprevious versions (or different versions) of a platform, according toone example embodiment.

FIG. 2 is a flowchart illustrating one embodiment of a method forcross-compiling for different versions, as described herein. Asillustrated by block 200, a multi-version compiler (e.g., multi-versioncompiler 100) as well as library data for a plurality of versions of aprogramming platform supported by the compiler (e.g., library data140A-D), may be installed. For example, a development system may includea multi-version compiler and library data regarding multiple versions(e.g., different versions, families, editions, releases, updates, etc.of one or more platforms of a programming platform) supported by thecompiler. Rather than requiring a developer to separately obtain orprovide library data for each version of a programming platformsupported by the compiler the library data may be provided with, or aspart of, the multi-version compiler.

In some embodiments, the compiler and the library data may be installedas part of a single installation. Additionally, library data for one ormore versions of a programming platform may be installed when thecompiler is installed, but additional library data (e.g., for differentversions) may also be installed at a later time, but may still beconsidered part of the compiler. In some embodiments, the compiler andlibrary data may be installed together locally, such as to the samemachine, system or storage device, but in other embodiments, thecompiler and library data may be installed remotely from each other, butmay still be considered part of the same development system.

In one embodiment, library data repository 130 may include library datathat may represent various different versions (or families, editions,releases, updates, etc.) of a programming platform or may representdifferent versions of a programming platform. For instance, a Java-basedmulti-version compiler configured to use the current version of the JRE(e.g., by default) may also include library data (e.g., informationregarding the types, interfaces, classes, methods, APIs, etc.) for oneor more other versions of the JRE, according to one embodiment. Themulti-version compiler may also support versions that represent bothearlier and later versions (e.g., families, editions, releases, updates,etc.) of the programming platform. For example, a Java-basedmulti-version compiler may support version 8 of the JRE by default, butmay also support earlier versions (e.g., versions 6 and 7) and laterversions (e.g., version 9) of the JRE.

Additionally, a multi-version compiler may be configured to supportdifferent versions of different programming platforms, according to someembodiments. For example, a Java-based multi-version compiler may, bydefault, support a particular version or profile of the JRE, but mayalso be configured to generate compiled code targeting various versionsof Java ME and/or various versions of Java SE.

As illustrated in block 210, the compiler may receive and/or accesssource code to be compiled. For instance, multi-version compiler 100 mayreceive or access source code 150 to be compiled. Source code 150 mayrepresent one or more files including program instructions to becompiled by multi-version compiler 100 into compiled code 170. Thesource code may be written in any of various languages and may also bewritten according to a previous (e.g., earlier) programing languagespecification that may correspond to the particular target version. Forinstance, in one example, a Java-based compiler that, by default, usesthe version 8 Java language specification may receive source codewritten according to the version 6 or version 7 of the Java programminglanguage.

By default, a multi-version compiler, such as multi-version compiler100, may be configured to compile (e.g., by default) against themost-recent version of programming platform APIs (or those that weremost recent when the compiler was released). Therefore, by defaultcompiled code may be configured to only use APIs that are available inthat particular version of the programming platform. Thus, a developermay specify a version option to the compiler specifying that thecompiler should compile source code into compiled code targeted to aparticular target version that may be different than the default versiontargeted by the compiler. For example, the compiler may also receive acompile command to compile the source code that includes a versionoption specifying a particular version, of multiple versions of aprogramming platform supported by the compiler, to be targeted by thecompiler when compiling the source code, as in block 220.

In one embodiment, multi-version compiler 100 may receive compilecommand 160 that includes version option 165. Version option 165 mayspecify a particular version as a target for compiling source code 150.For example, in one embodiment, version option 165 may represent acommand line option, such as a “-platform” or “-release” optionspecifying a particular release version of a programming platform whichmulti-version compiler 100 should target when compiling source code 150.Thus, in this example, compiled code 170 may be compiled according to aparticular language version, execute according to (and use) the types,interfaces, APIs, etc. of, a particular platform version (i.e., ratherthan according to a default version that the compiler may be configuredto use normally) indicated by the specified release version.

For example, the multi-version compiler may accept various userconfigurable options, such as via a command line, build utility, and/orgraphical user interface, one of which may be used to indicate aparticular version of a programming platform to be used as a target forcross-compiling by the multi-version compiler. For instance, in oneexample embodiment, a javac compiler that by default targets a currentversion of the JRE may be configured to cross-compile source codetargeting a previous version of the JRE. Thus, the compiled code may beconfigured to execute according to the previous version of the JRE. Forinstance, the compiled code may utilize the types, classes, methods,APIs, etc. as defined in the previous version of the JRE rather than asthey may be defined in the current version of the JRE.

The particular version (or the particular version of a particularplatform) may be identified (e.g., specified) via a single compileroption in any of various manners, according to various embodiments. Forexample, in one embodiment, the target version may be identified byname, while in another embodiment the target version may be identifiedby a unique ID, such as a version or release number. In general,versions of a programming platform may be identified (or specified)using any suitable method or technique.

Thus, version option 165 may include a value specifying or identifyingthe particular version to be targeted. For instance, a version option,such as “-platform N” or “-release N” may include a single valuecorresponding to a particular version (e.g., N may represent a versionnumber or name, such as “6” or “Java6”).

In one Java-based embodiment, the javac compiler may accept “-platform”as an option (e.g., via a command line or programmatic interface option)indicating a particular version of the JRE to target whencross-compiling source code. The “-platform” option (whether set via acommand line, build utility or graphical user interface) may be receivedby the compiler and indicate that the compiler should produce compiledcode according to a particular executable output format (e.g., classfiles when using a Java-based example) targeted to the specified targetversion (e.g., the particular version, family, release, update, etc. ofa JRE).

In some embodiments, multi-version compiler 100 may include commandinterface 120 that may be configured to receive compile command 160,identify version option 165 and determine the specified version.Additionally, command interface 120 may be configured to locate thelibrary data and pass information to compile engine 110 specifying theparticular target version and the location of the library data thatshould be used to compile source code 150. In other embodiments, howevercommand interface 120 may be configured to simply analyze compilecommand 160, identify version option 165 and provide version option 165(and/or any value of version option 165) to compile engine 110, whichmay then access and use the appropriate library data.

While described herein as being separate, in some embodiments, commandinterface 120 and compile engine 110 may only represent a logicalseparation to describe different aspects of multi-version compiler 100,and thus multi-version compiler 100 may not include a separate commandinterface or a separate compile engine.

In response to compile command 160 with the included version option 165,the compiler may be configured to access library data for the specifiedversion from a library data repository that includes library data forthe versions supported by the compiler, as illustrated in block 230. Insome embodiments, the library data repository may be part of thecompiler, as described above regarding block 200 of FIG. 2 . The librarydata in the library data repository may be stored in any of variousformats, according to different embodiments, as will be discussed inmore detail regarding subsequent figures. As noted above, the librarydata for the target version may include various types of information,such as information regarding the types, interfaces and API's for thespecified version.

The compiler may compile the source code into compiled code targeted tothe specified version using the appropriate library data from thelibrary data repository, as in block 240 and output the compiled code,as in block 250. For example, multi-version compiler may compile sourcecode 150 into compiled code 170 using library data 140A and targetingthe version of the programming platform.

Additionally, the version option 165 may also indicate a particular setof library data, such as library data 140A-D, to be used whencross-compiling source code 150. For example, version option 165 mayindicate (e.g., indirectly), a particular location within library datarepository 130 from which to load library data for use whencross-compiling. Rather than requiring the developer to provide, andspecify the location of, the library data, the library data for theversions supported by the compiler may by supplied with the compiler. Insome embodiments, multi-version compiler 100 may include compile engine110 that may be configured to perform the actual compiling of the sourcecode and may receive information from command interface 120 thatspecifies the particular target version, and/or the location of thelibrary data to use when compiling source code 150, as described above.

A developer may specify a target version of a programming platform totarget using the single version option without separately specifying asource version, a target version, or the location of the appropriatelibrary data, according to some embodiments.

Thus, in some embodiments, the compile command 160 may not specify thelocation of the library data to be used when compiling the source code.In other words, the developer may specify the target release versionusing a single version option (e.g., such as via a “-platform” or“-release” option) and from that single option, the compiler may compilethe source code into compiled code targeted to the specified versionusing the library data indicated by the specified release version.

In some embodiments, one or more parts (e.g., modules, sections,functions, methods, etc.) of multi-version compiler 100 may not beconfigured to recognize the value of the version option 165. Thus, inresponse to the single compiler option (e.g., compile command 160 withversion option 165) being used to specify a target release version,command interface 120 may interpret compile command 160 and versionoption 165 to provide the specified information to other portions of thecompiler, such as to compile engine 110, in a different manner orformat.

For instance, according to one Java-based embodiment, one or moreportions of the javac compiler may recognize a -source, a -target and/ora -bootclasspath option, but may not recognize a “-platform” option.Therefore, one portion of the compiler, such as command interface 120may use the value of the “-platform” option to provide the specifiedinformation to other portions of the compiler, such as to compile engine110, using a -source, a -target and/or a -bootclasspath option,according to one example embodiment.

In one embodiment, command interface 120 may macro-expand the singlecompiler option into the other format for use by compile engine 110. Forinstance, using a Java-based example, a multi-version compiler may beconfigured to macro-expand:

-   -   -platform N

into:

-   -   -source N -target N -bootclasspath ct-N.sym

where ct-N.sym identifies a ct.sym file representing the library datafrom the JRE version N. Thus, in some embodiments, an option such as“-platform N” or “-release N” may be considered the equivalent of“-source N -target N -bootclasspath ct-N.sym.”

In some embodiments, command interface 120 may represent a make or buildutility that may configure the additional compiler options based on thesingle compiler option before executing the multi-version compiler(e.g., macro expanding the “-platform” (or “-release”) option intoseparate “-source”, “-target” and “-bootclasspath” options).

Additionally, cross-compiling may involve accessing library data for thetarget release version of the programming platform. As noted above,library data regarding various versions of a programming platform,regarding various versions of various platforms of a programmingplatform, or a combination of the two, may be stored within a librarydata repository that is part of, or is accessible by, the multi-versioncompiler. For instance, in one embodiment, one or more files installedas part of multi-version compiler 100 may include library data for aplurality of versions supported by the compiler and multi-versioncompiler 100 may be configured to access library data from those files.Alternatively, in another embodiment, the multi-version compiler 100 mayinclude a programmatic interface allowing the compiler to accessremotely stored library data regarding a particular version (e.g., overa local network, over the Internet, via a web-based service interface,etc.).

As noted above, library data may include, but may not be limited to,information regarding the types, classes, methods, APIs, interfaces,etc., of the target release version.

The particular manner in which the library data is accessed and theexact data format of the library data may vary from embodiment toembodiment, as will be discussed in more detail subsequently.

Returning to FIG. 2 , after accessing the relevant library data for thetarget release version, a multi-version compiler may compile the sourcecode into compiled code targeted to the particular version using theparticular library data and according to a particular version of aprogramming platform supported by the compiler, as shown in block 240.Thus, the compiled code may be configured to execute according to thetarget release version. Additionally, the compiler may be configured tooutput the compiled code as in block 250. For instance, in oneembodiment, multi-version compiler 100 may be configured to generate oneor more class files. In other embodiments, multi-version compiler 100may be configured to output compiled code in various formats, such as bygenerating class files, object files, library files, etc.,

By utilizing a single command option, such as a “-platform” or a“-release” option, a developer may more easily (e.g., than when usingtraditional methods) cross compile the same source for multiple,different versions of a programming platform, according to someembodiments. FIG. 3 is a flowchart illustrating one embodiment of amethod cross-compiling for multiple versions, according to oneembodiment. As illustrated in block 300, a multi-version compiler mayreceive source code to be compiled and may also receive a compilecommand that includes a version option specifying a particular version,as in block 310. As described above, multi-version compiler 100 mayreceive source code 150 as well as compile command 160 that includesversion option 165, according to some embodiments.

The compiler may then compile the source code into compiled codetargeted to the particular version using library data from a librarydata repository, as shown in block 320. For instance, in one embodiment,multi-version compiler 100 may, in response to receiving compile command160 with version option 165, may compile source code 150 using librarydata 140A from library data repository 130. Multi-version compiler 100may access library data 140A from a particular location in library datarepository 130 based, at least in part, on the value of version option165.

Subsequently, the compiler may receive another compile command thatincludes a version option specifying a different version, as illustratedin block 330. In response, the compiler may compile the same source codeinto different compiled code targeted to the different version usingdifferent library data from the library data repository, as illustratedin block 340. For instance, multi-version compiler 100 may receiveanother compile command 160 that includes another version option 165that specifies the different version. In response, multi-versioncompiler 100 may access library data 140B from library data repository130 for use when compiling the source code.

In one example embodiment, a javac compiler may receive a compilecommand that includes a version option specifying version 6 of the JREand in response may compile the source code into class files targetingversion 6 of the JRE using library data corresponding to version 6 ofthe JRE. Subsequently the javac compiler may receive another compilecommand that includes another version option specifying version 7 of theJRE and in response may compile the source code into class filestargeting version 7 of the JRE using library data corresponding toversion 7 of the JRE.

Thus, a developer may utilize the same compile option with differentvalues (e.g., such as a “-platform” or a “-release” option in someembodiments) to cross compile the same source code targeting differentversions without having to obtain, provide and/or separately specifyingmultiple compile options, according to some embodiments.

FIG. 4 is a flowchart illustrating one embodiment of a method foraccessing library data for a target release version, as describedherein. A multi-version compiler may be configured to access librarydata for the target release version from a library data repository thatincludes library data for multiple versions of a programming platformsupported by the compiler, as in block 400. In some embodiments, thelibrary data in the library data repository may be formatted as abaseline set of library data and various sets of differential librarydata for individual versions supported by the compiler.

As shown in block 410, a multi-version compiler may access baselinelibrary data from a library data repository and may also accessdifferential library data representing differences from the baselinelibrary data, as shown in block 420. For example, in one embodiment, thebaseline library data may correspond to an initial (e.g., earliest orearliest supported) version of the programming platform while thedifferential library data may include information indicating one or moredifferences between that initial version and a later version of theprogramming platform.

In some embodiments, the baseline library data may correspond to aversion of the programming platform that is subsequent to (i.e., laterthan) the target release version. Furthermore, in some embodiments, thebaseline library data correspond to a version of the programmingplatform that is earlier than some (e.g., one or more) and later thanothers (e.g., one or more) of the other versions for which differentialinformation may be accessed.

In other embodiments, however, the baseline set of library data may notcorrespond to any particular version (or family, edition, release,update, etc.) of the programming platform at all, but may simply be (ormay represent) a baseline set the library data to which differentiallibrary data is applied to determine (or generate) complete library datafor the various versions supported by the compiler.

As shown in block 430, the multi-version compiler may determine librarydata for the target version based, at least in part, on applying thedifferential library data to the baseline library data. Thus, thedifferential library data may be used to determine the library data forthe target release version, according to some embodiments. For example,if a new method (or type, interface, class, API, etc.) were added to thetarget release version that was not part of the baseline version (in anembodiment in which the baseline library data corresponds to a versionof the programming platform), information regarding the added method maybe included as part of the differential library data for the targetrelease version. Similarly, if a method (or type, interface, class, API,etc.) that was part of the baseline version was removed from the targetrelease version, the differential library data may include informationindicating that the method is not part of the target release versioneven if it was part of the baseline version. Additionally, if a method(or type, interface, class, API, etc.) was changed in the target releaseversion as compared to the same method (or type, interface, class, API,etc.) in the baseline version, information indicating the differencesbetween the version of the method (or type, interface, class, API, etc.)in the target release version compared to the version in the baselineversion.

Thus, the multi-version compiler may determine library data for thetarget release version by applying the differential library data to thebaseline library data, according to some embodiments. In one embodiment,the multi-version compiler may be configured to build a complete set oflibrary data by modifying a copy of the baseline library data accordingto the differential library data. In another embodiment however, themulti-version compiler may be configured to utilize both the baselinelibrary data and the differential library data as needed when compilingthe source code without building a complete set of library data for thetarget release version, as will be explained in more detail belowregarding FIG. 5 .

As shown in block 440, the multi-version compiler may compile the sourcecode using the determined library data for the target release version,according to some embodiments.

FIG. 5 is a logical block diagram illustrating a repository of librarydata including baseline library data and differential library data,according to one embodiment.

For example, multi-version compiler 100 may include, or may beconfigured to access, library data repository 130 that may includelibrary data for various versions of a programming platform (e.g.,various families, editions, versions, editions, updates, or releases,etc. of one or more programming platforms) supported by the compiler. Asnoted above, library data may include information, such as informationregarding the types, APIs, interfaces, etc., used when compiling forparticular versions and the library data repository may include librarydata for various versions supported by the compiler.

Thus, library data repository 130 may include baseline library data 500as well as one or more sets of differential library data, such asdifferential library data 510A, 510B, 510C, and 510D, according to oneexample embodiment. For instance, baseline library data 500 may be,include, or represent, a complete set of library data for a baselineversion (family, edition, release, update, etc.) of the programmingplatform while differential library data 510A-D may be, include orrepresent, information indicating differences between the baselineversion and a different version (or family, edition, release, update,etc.) of the programming platform.

In other embodiments, rather than representing library data forparticular baseline version, baseline library data 500 may represent abaseline set of library data from which complete library data for thesupported versions may be determined, such as by applying differentiallibrary data 510A, 510B, 510C and/or 510D to baseline library data 500.

Baseline library data 500 may, in one embodiment, represent informationregarding a particular version while differential library data 510A-Dmay represent information for multiple other versions. For instance, inone embodiment, baseline library data 500 may represent library data forthe earliest (or the earliest supported) version while differentiallibrary data 510A-D may represent differences between the baselinelibrary data and various other versions. In other embodiments, however,baseline library data 500 may represent library data for a version thatis earlier than some, while later than other, target release versions(represented by differential library data 510A-D).

In yet other embodiments, baseline library data 500 may not representcomplete library data for any particular version, but instead mayrepresent a set of baseline data from which complete library data forthe various versions supported by the compiler may be determined orgenerated, such as applying differential library data 510A to baselinelibrary data 500.

In some embodiments, rather than directly indicating differences frombaseline library data 500, one or more of differential library data510A-D may indicate difference from another set of differential librarydata. For instance, in one embodiment, differential library data 510Amay include information indicating one or more differences from baselinelibrary data 500 while differential library data 510B may includeinformation indicating one or more differences from differential librarydata 510A. Additionally, differential library data 510C may includeinformation indicating one or more differences from differential librarydata 510B, according to one example embodiment. Thus, in someembodiments, multi-version compiler 100 may have to access baselinelibrary data 500 as well as multiple sets of differential library datain order to determine library data for a particular target releaseversion.

In some embodiments, the baseline library data as well as each set ofdifferential library data may all be stored in a single file, but inother embodiments, the library data may be split into multiple, smaller,files (such as to avoid having a single, large, file in a repository).In general, library data, such as baseline library data 500 anddifferential library data 510A-D may be stored in virtually any suitablemanner and according to virtually any suitable data format.

As noted above, in some embodiment, library data repository 130, as wellas baseline library data 500 and differential library data 510A-D may belocal to multi-version compiler 100. In other embodiments, however,library data repository 130, as well as baseline library data 500 anddifferential library data 510A-D may be remote from (e.g., storedseparately or on a separate storage device) multi-version compiler 100.In yet other embodiments, library data repository 130 may be distributedwith one or more of sets of library data (e.g., baseline library data500 and/or differential library data 510A-D) local to multi-versioncompiler 100, while other sets of library data (e.g., baseline librarydata 500 and/or differential library data 510A-D) remote frommulti-version compiler 100.

FIG. 6 is a logical block diagram illustrating a repository of librarydata using a multi-version directory structure, according to oneembodiment. As described above, in some embodiments, library data forvarious target versions may be stored in a repository in any of variousformats. FIG. 6 illustrates, according to one embodiment, library datastored using a directory structure. For example, library data repository130 may include multiple files stored within various directories andeach directory may include one or more files including library data forone or more versions. In some embodiments, the information included inany particular directory may represent library data for one or moreversions. Additionally, the library data for any particular version maybe spread across multiple directories. Additionally, the library datamay be formatting in terms of baseline and differential data, asdescribed above regarding FIG. 4 and FIG. 5 , within a directorystructure such as the one illustrated in FIG. 6 . Thus, a multi-versioncompiler may access files from one or more of the directories in orderto determine the library data for a particular target version.

For example, as illustrated in FIG. 6 , library data repository 130 mayinclude, in this example, six directories that collectively includelibrary data for three different target versions of a programmingplatform (e.g., versions 6, 7, and 8 of an example programmingplatform), according to one embodiment. In some embodiments, the name ofa directory may indicate for which versions that particular directoryincludes library data. For instance, directory 600 may be named (or mayinclude as part of its name) “6” indicating that it includes librarydata for version 6 of the programming platform. Similarly, directory 610may include “6” as part of its name indicating that it too includeslibrary data for version 6 of the programming platform. Additionally,directory 620 may also include “6” as part of its name indicating thatit also includes library data for version 6 of the programming platform.

Thus, in the example embodiment illustrated in FIG. 6 , directories 600,610 and 620 may each include (at least partial) library data for version6 of the programming platform. A directory, such as directory 600, mayonly include library data for a particular version, such as for version6 of the programming platform. Alternatively however, a directory, suchas directory 610, may include library data that is common to more thanone version, such as library data that is common to both version 6 andversion 7. Thus, a directory may include library data for virtually anynumber of versions (families, editions, releases, updates, etc.) of aplatform. For example, directory 620 may include library data that iscommon to versions 6, 7, and 8, according to the example embodimentillustrated in FIG. 6 . Similarly, directory 630 may include librarydata for version 7, directory 640 may include library data common toversions 7 and 8, while directory 650 may include library data forversion 8.

The exact nature and format of the library data that is stored inlibrary data repository 130 may vary from embodiment to embodiment. Forexample, in one Java-based embodiment, the library data for the varioustarget versions may be stored using one or more rt.jar files. In otherembodiments, one or more ct.sym files may be used to store the librarydata. In one embodiment, a ct.sym file may be, or may include, strippeddown versions (e.g., not include the bodies of methods, etc.) ofclassfiles corresponding to the classfile of the particular targetrelease version. In yet other embodiments, a combination of differentfiles may be used to store library data when using a directorystructure, such as the one illustrated in FIG. 6 .

Additionally, library data may be stored using a combination oftechniques. For instance, in one embodiment, library data may be storedusing a directory structure, such as that illustrated in FIG. 6 , butalso using a baseline and differential technique, such as that describedabove. For instance, directory 600 may include a baseline version oflibrary data while directories, 610, 620, 630, 640 and 650 may includedifferential information (directory 610 may include differentialinformation for library data that is common to both versions 6 and 7).

Additionally, in some embodiment, library data repository 130, as wellas library data in directories 600, 610, 620, 630, 640 and 650, may belocal to multi-version compiler 100. In other embodiments, however,library data repository 130, as well as library data in directories 600,610, 620, 630, 640 and 650, may be remote from (e.g., stored separatelyor on a separate storage device) multi-version compiler 100. In yetother embodiments, library data repository 130 may be distributed withone or more of sets of library data (e.g., library data in directories600, 610, 620, 630, 640 and 650) local to multi-version compiler 100,while other sets of library data (e.g., library data in directories 600,610, 620, 630, 640 and 650) remote from multi-version compiler 100.

Thus, an individual piece of library data, such as an individual type,that is only be present for a particular version of the programmingplatform may only be present within a single directory for that versionof the programming platform. For example, a type that should only bepresent for version 6 of the JRE may only be included in the librarydata in directory 600 (e.g., the version “6” directory) without beingincluded in the library data in directories 610 or 620, even thoughthose directories may include other library data for version 6,according to one Java-based embodiment.

When utilizing library data stored using a directory structure, thedirectories may or may not be actual physical directories within a filesystem, according to various embodiments. For example, in someembodiments, the library data may be stored within a single, large, filewhile being structured according to various directories within the file.For instance, a ct.sym file may include various directories holdinglibrary data for target release versions, according to one Java-basedembodiment.

Additionally, continuing with a Java-based example, the bootclasspathfor a particular version N may then be composed of directories thatinclude N (e.g., in the directory name). Each directory may include oneor more classfiles representing (or defining) the library data for thevarious target versions. In some embodiments, the classfiles in thedirectories may represent ordinary classfiles that may be used in anymanner that classfiles are otherwise used.

While described above using the directory names as indicators of theparticular library data included in a particular directory, the mannerin which a multi-version compiler may determine what library data isincluded in which directories may vary from embodiment to embodiment.For instance, in one embodiment, a separate file may map the contents ofthe directories, such that the multi-version compiler may utilize themap to determine which directories include the relevant library data forany particular target version. In general, any suitable method,technique or mechanism that allows a multi-version compiler to determinewhich directory (or directories) includes library data for a particulartarget version may be used when storing library data using a directorystructure, as described herein.

Additionally, in some embodiments, multi-version compiler 100 and/orlibrary data repository 130 may be configured to compile baseline anddifferential library data with a multi-version directory structure. Forinstance, in one embodiment, library data repository may include a setof baseline library data, such as in directory 600 for example, to whichlibrary data from other directories may be applied to determine librarydata for versions of the programming platform supported by amulti-version compiler 100.

When accessing library data for a target version using a directorystructure, such as that illustrated above regarding FIG. 6 , amulti-version compiler may be configured to access/read the library datafor the target release version from one or more directories within thedirectory structure, according to various embodiments. FIG. 7 is aflowchart illustrating one embodiment of a method for accessing librarydata stored using a directory structure, as described herein. As shownin block 700, and described above, a compiler may be configured toaccess library data from a library data repository that includes librarydata for multiple release versions of a programming platform supportedby a multi-version compiler, as described above regarding block 230 ofFIG. 2 and block 400 of FIG. 4 .

As shown in block 710, a multi-version compiler may be configured todetermine one or more directories that include library data for thetarget release version. For example, multi-version compiler 100 may beconfigured to scan the directory structure to determine, such as byusing the names of the individual directories, one or more of thedirectories that include library data for the target release version.Thus, according to one example embodiment, multi-version compiler 100may determine that directories 600, 610 and 620 include informationregarding version 6 of the programming platform. Similarly, if targetingversion 7, multi-version compiler 100 may determine that directories610, 620 and 630 include the appropriate library data.

Additionally, a multi-version compiler may be configured to determinelibrary data for the target version based on the information included inthe directories, as shown in block 720. For instance, after determiningthat directories 600, 610 and 620 include library data for version 6, amulti-version compiler may read that library data from those directoriesfor use when cross-compiling.

In some embodiments, the multi-version compiler may combine theinformation from individual directories to build a complete set oflibrary data for the target release version. For instance, using theexample embodiment illustrated in FIG. 6 above, multi-version compiler100 may combine the information from directory 600, directory 610 anddirectory 620 to build a complete set of library data for version 6.However, in other embodiments, multi-version compiler 100 may notcombine the information from multiple directories and may insteadutilize the library data individually as needed.

Additionally, the library data within the directory structureillustrated in FIG. 6 may also be formatted as baseline and differentialdata as described above regarding FIG. 4 and FIG. 5 . Thus,multi-version compiler 100 may be configured to apply the library datafrom one or more of the directories to baseline library data whendetermining (or generating) library data for a particular target releaseversion, according to some embodiments.

A multi-version compiler may then cross-compile a software module using(or according to) the determined library data, as shown in block 730.For example, multi-version compiler 100 may cross-compile a softwaremodule, targeting version 6 of the programming platform, according tothe library data accessed from directories 600, 610 and 620. As notedabove, when cross-compiling for a particular target release versionaccording to library data for that particular version, a multi-versioncompiler may be configured to ensure that the software module, oncecompiled, may execute according to the types, methods, classes, APIsand/or interfaces for the target version as defined in the library datafor the target version.

FIG. 8 is a logical block diagram illustrating a library data repositoryincluding multiple platforms with multiple versions (families, editions,releases, updates, etc.), according to one embodiment. In someembodiments, multi-version compiler 100 may be configured to supportmultiple programming platforms as well as multiple versions (families,editions, releases, updates, etc.) of one or more programming platforms.For example, multi-version compiler 100 may support one or more versionsof Java SE as well as one or more versions of Java ME, according to oneembodiment. Additionally, library data repository 130 may also support(e.g., hold, maintain, store, etc.) library data for multiple platforms.Thus, library data repository 130 may include library for multipleplatforms, such as platform 800A, platform 800B and platform 800C. Asnoted above, library data may include, but may not be limited to,information regarding the types, APIs, interfaces, etc., used whencompiling source code for a version (family, edition, release, update,etc.) of programming platforms supported by multi-version compiler 100.

Each platform supported by multi-version compiler 100 may have one ormore versions (families, editions, releases, updates, etc.) each with acorresponding version of library data needed by multi-version compiler100 in order to target that particular version, according to variousembodiments. For example, platform 800A may have five different(supported) versions and library data repository 130 may include librarydata for each one, such as library data 810, library data 820, librarydata 830, library data 840 an library data 850, illustrated in FIG. 8 .Other platforms supported by multi-version compiler 100 may includedifferent numbers of versions and library data repository may thereforeinclude different numbers of versions for different supported platforms.For example, platform 800B may have three (supported) versions andtherefore library data repository 130 may include three different setsof library data for platform 800B, such as library data 860, librarydata 870 and library 880. One or more supported platforms may onlyinclude one (supported) version and therefore library data repository130 may only include one set of library data, such library data 890 ofplatform 800C.

FIG. 8 represents a logical arrangement of library data within librarydata repository 130 and does not necessarily represent an actualphysical arrangement of library data. For instance, library data fordifferent versions of a platform may not be stored together orcontiguously within library data repository 130 and a library datarepository 130 may not include any actual data structure correspondingto platforms 800A, 800B and/or 800C. Library data repository 130 mayidentify library data versions as belonging to different platforms inany of various manners, according to different embodiments. For example,in some embodiments, library data repository 130 may include informationthat maps a particular version (e.g., family, edition, release, update,etc.) of library data to a platform, either within the library dataitself or separately. In other embodiments, library data repository 130may group library data for different platforms into different groupings,such as in a hierarchy, according to the respective platforms to whichthe versions belong. In general, any suitable method or technique ofidentifying which library data correspond to different platforms may beutilized according to various embodiments.

Additionally, when multi-version compiler 100 supports multipleplatforms (and/or multiple versions of multiple platforms), the librarydata for supported versions of those platforms may be stored within datarepository 130 using any of various techniques described herein. Forexample, in one embodiment, the library data within library datarepository 130 may be stored utilizing baseline and differential librarydata, as described above.

When using baseline and differential library data, library datarepository 130 may include a baseline set of library data as well asdifferential library for each platform, according to one embodiment. Inother words, library data 810 may represent baseline library data forplatform 800A, while library data 860 may represent baseline librarydata for platform 800B, while library data 890 may represent a completeset of library data (since example platform 800C only includes onesupported version) in one example embodiment.

In other embodiments, however, library data repository 130 may include aset of baseline library data (not illustrated in FIG. 8 ) to which otherlibrary data may be applied. For instance, library data 810, 820, 830,840 and 850 may represent differential data that may be applied to thebaseline library data to determine library data for the varioussupported versions of platform 800A. Similarly, library data 860, 870and 880 may represent differential data that may be applied to thebaseline library data to determine library data for the varioussupported versions of platform 800B. Additionally, library data 890 mayrepresent differential data that may be applied to the baseline librarydata to determine library data for the supported version of platform800C.

Furthermore, in some embodiments, library data repository 130 may beconfigured to store library data using a multi-version directorystructured, such as described above regarding FIG. 6 that includelibrary data for multiple platforms. For example, library data 810, 820,830, 840 and 850 may represent multiple directories, each storinglibrary data for one or more supported versions of platform 800A andmulti-version compiler 100 may be configured to access one or more ofthe directories to determine library data for a particular version ofplatform 800A.

In some embodiments, library data repository 130 may be configured tocombine the use of a multi-version directory structure as well baselineand differential library data when supporting multiple platforms. Forexample, in one embodiment, library data 810 may represent baselinelibrary data for platform 800A and library data 820, 830, 840 and 850may represent differential library data stored using a multi-versiondirectory. Thus, multi-version compiler 100 may be configured to accesslibrary 810 to obtain the baseline library data and to apply one or moreof library data 820, 830 840 and/or 850 as differential library data tothe baseline library data when determining library data for a specifiedversion (e.g., family, edition, release, update, etc.) of platform 800Asupported by multi-version compiler 100.

In at least some embodiments, a computer system that implements aportion or all of one or more of the technologies described herein mayinclude a general-purpose computer system that includes or is configuredto access one or more computer-readable media. FIG. 9 illustrates such ageneral-purpose computing device 3000 suitable for implementing themethod, features and enhancements described herein. In the illustratedembodiment, computing device 3000 includes one or more processors 3010coupled to a system memory 3020 via an input/output (I/O) interface3030. Computing device 3000 further includes a network interface 3040coupled to I/O interface 3030.

In various embodiments, computing device 3000 may be a uniprocessorsystem including one processor 3010 or a multiprocessor system includingseveral processors 3010 (e.g., two, four, eight, or another suitablenumber). Processors 3010 may include any suitable processors capable ofexecuting instructions. For example, in various embodiments, processors3010 may be general-purpose or embedded processors implementing any of avariety of instruction set architectures (ISAs), such as the x86,PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. Inmultiprocessor systems, each of processors 3010 may commonly, but notnecessarily, implement the same ISA.

System memory 3020 may be configured to store program instructions anddata accessible by processor(s) 3010. In various embodiments, systemmemory 3020 may be implemented using any suitable memory technology,such as static random access memory (SRAM), synchronous dynamic RAM(SDRAM), nonvolatile/Flash-type memory, or any other type of memory. Inthe illustrated embodiment, program instructions and data implementingone or more desired functions, such as those methods, techniques, anddata described above, are shown stored within system memory 3020 as code(i.e., program instructions) 3025 and data 3026. For example, memory3020 and well as code 3025 and data 3026 may store, in one embodiment,program instructions and data for implementing multi-version compiler100, compile engine 110 and/or command interface 120, described above.

In various embodiments, multi-version compiler 100, compile engine 110and/or command interface 120 (and/or any individual sub-modules thereof)may each be implemented in any of various programming languages ormethods. For example, in one embodiment, multi-version compiler 100,compile engine 110 and/or command interface 120 may be written in any ofthe Java, C, C++, assembly, or other general purpose programinglanguages, while in another embodiment, one or more of them may bewritten using a different, more specialized, programming language.Moreover, in some embodiments, multi-version compiler 100, compileengine 110 and/or command interface 120 (and/or various sub-modulesthereof) may not be implemented using the same programming language.

In one embodiment, I/O interface 3030 may be configured to coordinateI/O traffic between processor 3010, system memory 3020, and anyperipheral devices in the device, including network interface 3040 orother peripheral interfaces. In some embodiments, I/O interface 3030 mayperform any necessary protocol, timing or other data transformations toconvert data signals from one component (e.g., system memory 3020) intoa format suitable for use by another component (e.g., processor 3010).In some embodiments, I/O interface 3030 may include support for devicesattached through various types of peripheral buses, such as a variant ofthe Peripheral Component Interconnect (PCI) bus standard or theUniversal Serial Bus (USB) standard, for example. Also, in someembodiments some or all of the functionality of I/O interface 3030, suchas an interface to system memory 3020, may be incorporated directly intoprocessor 3010.

Network interface 3040 may be configured to allow data to be exchangedbetween computing device 3000 and other devices 3060 attached to anetwork or networks 3050. In various embodiments, network interface 3040may support communication via any suitable wired or wireless generaldata networks, such as types of Ethernet network, for example.

In some embodiments, system memory 3020 may be one embodiment of acomputer-readable (e.g., computer-accessible) medium configured to storeprogram instructions and data as described above with respect to FIGS.1-8 for implementing embodiments of the corresponding methods andapparatus. However, in other embodiments, program instructions and/ordata may be received, sent or stored upon different types ofcomputer-readable media. Generally speaking, a computer-readable mediummay include non-transitory storage media or memory media such asmagnetic or optical media, e.g., disk or DVD/CD coupled to computingdevice 3000 via I/O interface 3030. A non-transitory computer-readablestorage medium may also include any volatile or non-volatile media suchas RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that maybe included in some embodiments of computing device 3000 as systemmemory 3020 or another type of memory.

Further, a computer-readable medium may include transmission media orsignals such as electrical, electromagnetic, or digital signals,conveyed via a communication medium such as a network and/or a wirelesslink, such as may be implemented via network interface 3040. Portions orall of multiple computing devices such as that illustrated in FIG. 9 maybe used to implement the described functionality in various embodiments;for example, software components running on a variety of differentdevices and servers may collaborate to provide the functionality. Insome embodiments, portions of the described functionality may beimplemented using storage devices, network devices, or special-purposecomputer systems, in addition to or instead of being implemented usinggeneral-purpose computer systems. The term “computing device,” as usedherein, refers to at least all these types of devices, and is notlimited to these types of devices.

Various embodiments may further include receiving, sending, or storinginstructions and/or data implemented in accordance with the foregoingdescription upon a computer-readable medium or upon a computer-readablestorage medium. Generally speaking, a computer-readable medium mayinclude storage media or memory media such as magnetic or optical media,e.g., disk or DVD/CD-ROM, volatile or non-volatile media such as RAM(e.g. SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc. In some embodiments, acomputer-readable medium may also include transmission media or signalssuch as electrical, electromagnetic, or digital signals, conveyed via acommunication medium such as network and/or a wireless link.

The various methods as illustrated in the figures and described hereinrepresent exemplary embodiments of methods. The methods may beimplemented in software, hardware, or a combination thereof. In variousof the methods, the order of the steps may be changed, and variouselements may be added, reordered, combined, omitted, modified, etc.Various of the steps may be performed automatically (e.g., without beingdirectly prompted by user input) and/or programmatically (e.g.,according to program instructions).

While various systems and methods have been described herein withreference to, and in the context of, specific embodiments, it will beunderstood that these embodiments are illustrative and that the scope ofthe disclosure is not limited to these specific embodiments. Manyvariations, modifications, additions, and improvements are possible. Forexample, the blocks and logic units identified in the description arefor understanding the described embodiments and not meant to limit thedisclosure. For example, actions, processes, methods, tasks or functionsdescribed herein as being performed by multi-version compiler 100 may,in some embodiments, be performed by compile engine 110 and/or commandinterface 120 and vice versa. Additionally, functionality may beseparated or combined in blocks differently in various realizations ofthe systems and methods described herein or described with differentterminology.

These embodiments are meant to be illustrative and not limiting.Accordingly, plural instances may be provided for components describedherein as a single instance. Boundaries between various components,operations and data stores are somewhat arbitrary, and particularoperations are illustrated in the context of specific illustrativeconfigurations. Other allocations of functionality are envisioned andmay fall within the scope of examples that follow. Finally, structuresand functionality presented as discrete components in the exemplaryconfigurations may be implemented as a combined structure or component.

The various methods as illustrated in the figures and described hereinrepresent example embodiments of methods. The methods may be implementedin software, hardware, or a combination thereof. The order of method maybe changed, and various elements may be added, reordered, combined,omitted, modified, etc.

Although the embodiments above have been described in detail, numerousvariations and modifications will become apparent once the abovedisclosure is fully appreciated. Various modifications and changes maybe made as would be obvious to a person skilled in the art having thebenefit of this disclosure. It is intended that the invention embraceall such modifications and changes and, accordingly, the abovedescription to be regarded in an illustrative rather than a restrictivesense. Furthermore, it is intended that the following claims beinterpreted to embrace all such variations and modifications.

1-20. (canceled)
 21. A method, comprising: performing, by one or moreprocessors: applying differential library data of a library datarepository to baseline library data of the library data repository togenerate a specified release version of a library, the specified releaseversion different from a baseline version of the library correspondingto the baseline library data of the library data repository; compilingsource code into compiled code targeted to the specified releaseversion, the compiled code comprising one or more accesses to interfacesof the specified release version of the library; and outputting thecompiled code targeted to the specified release version.
 22. The methodof claim 21, further comprising: receiving a compile command to compilethe source code, the compile command comprising a version optionindicating the specified release version, wherein the specified releaseversion is one of a plurality of versions of a programming languagesupported by a compiler performing the compiling and outputting.
 23. Themethod of claim 22, wherein the programming language is the JavaProgramming Language.
 24. The method of claim 22, wherein the one ormore accesses to interfaces of the specified release version of thelibrary are generated according to application programming interface(API) information of the specified release version of the libraryaccessed from a location within the library data repository identifiedby the version option.
 25. The method of claim 22, further comprisinginstalling the compiler and library data including the baseline libraryand respective differential library data for the plurality of versionsin the library data repository, wherein the compiler and the librarydata for the plurality of versions are installed as part of a singleinstallation.
 26. The method of claim 21, wherein the baseline librarydata corresponds to an earlier version of a programming language ascompared to a version of the programming language to which thedifferential library data corresponds.
 27. The method of claim 21,further comprising: receiving a compile command to compile the sourcecode, the compile command comprising a version option indicating abaseline release version different from the specified release version;compiling source code into compiled code targeted to the baselinerelease version, the compiled code comprising one or more accesses tointerfaces of the baseline release version of the library; andoutputting the compiled code targeted to the baseline release version.28. One or more non-transitory, computer-readable storage media, storingprogram instructions that when executed on or across one or morecomputing devices, cause the one or more computing devices to implement:applying differential library data of a library data repository tobaseline library data of the library data repository to generate aspecified release version of a library, the specified release versiondifferent from a baseline version of the library corresponding to thebaseline library data of the library data repository; compiling sourcecode into compiled code targeted to the specified release version, thecompiled code comprising one or more accesses to interfaces of thespecified release version of the library; and outputting the compiledcode targeted to the specified release version.
 29. The one or morenon-transitory, computer-readable storage media of claim 28, storingadditional program instructions that when executed on or across one ormore computing devices, cause the one or more computing devices toimplement: receiving a compile command to compile the source code, thecompile command comprising a version option indicating the specifiedrelease version, wherein the specified release version is one of aplurality of versions of a programming language supported by a compilerperforming the compiling and outputting.
 30. The one or morenon-transitory, computer-readable storage media of claim 29, wherein theprogramming language is the Java Programming Language.
 31. The one ormore non-transitory, computer-readable storage media of claim 29,wherein the one or more accesses to interfaces of the specified releaseversion of the library are generated according to applicationprogramming interface (API) information of the specified release versionof the library accessed from a location within the library datarepository identified by the version option.
 32. The one or morenon-transitory, computer-readable storage media of claim 29, storingadditional program instructions that when executed on or across one ormore computing devices, cause the one or more computing devices toimplement: installing the compiler and library data including thebaseline library and respective differential library data for theplurality of versions in the library data repository, wherein thecompiler and the library data for the plurality of versions areinstalled as part of a single installation.
 33. The one or morenon-transitory, computer-readable storage media of claim 28, wherein thebaseline library data corresponds to an later version of a programminglanguage as compared to a version of the programming language to whichthe differential library data corresponds.
 34. The one or morenon-transitory, computer-readable storage media of claim 28, storingadditional program instructions that when executed on or across one ormore computing devices, cause the one or more computing devices toimplement: receiving a compile command to compile the source code, thecompile command comprising a version option indicating a baselinerelease version different from the specified release version; compilingsource code into compiled code targeted to the baseline release version,the compiled code comprising one or more accesses to interfaces of thebaseline release version of the library; and outputting the compiledcode targeted to the baseline release version.
 35. A system, comprising:at least one processor; a memory, comprising program instructions thatwhen executed by the at least one processor cause the at least oneprocessor to implement a compiler configured to: apply differentiallibrary data of a library data repository to baseline library data ofthe library data repository to generate a specified release version of alibrary, the specified release version different from a baseline versionof the library corresponding to the baseline library data of the librarydata repository; compile source code into compiled code targeted to thespecified release version, the compiled code comprising one or moreaccesses to interfaces of the specified release version of the library;and output the compiled code targeted to the specified release version.36. The system of claim 35, the compiler further configured to: receivea compile command to compile the source code, the compile commandcomprising a version option indicating the specified release version,wherein the specified release version is one of a plurality of versionsof a programming language supported by the compiler.
 37. The system ofclaim 36, wherein the programming language is the Java ProgrammingLanguage.
 38. The system of claim 36, wherein the one or more accessesto interfaces of the specified release version of the library aregenerated according to application programming interface (API)information of the specified release version of the library accessedfrom a location within the library data repository identified by theversion option.
 39. The system of claim 35, wherein the baseline librarydata corresponds to an earlier version of a programming language ascompared to a version of the programming language to which thedifferential library data corresponds.
 40. The system of claim 35, thecompiler further configured to: receive a compile command to compile thesource code, the compile command comprising a version option indicatinga baseline release version different from the specified release version;compile source code into compiled code targeted to the baseline releaseversion, the compiled code comprising one or more accesses to interfacesof the baseline release version of the library; and output the compiledcode targeted to the baseline release version.